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TO ALL WHOM IT MAY CONCERN: 

Be it known that we. Ken D. Krivoshein a citizen of the United 
States, residing at 183 Elgin Woods Lane, Elgin, Texas 78621 in the County 
of Bastrop, and Dan D. Christensen a citizen of the United States, residing at 
9001 Marthas Drive, Austin, Texas 78717 in the County of Travis, have 
invented a new and useful PROCESS CONTROL SYSTEM INCLUDING 
AUTOMATIC SENSING AND AUTOMATIC CONFIGURATION OF DEVICES, of 
which the following is a specification. 
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BACKGROUND OF THE INVENTION 

1. field of the Invention 

This invention relales to process control systems. More 
specifically, the present invention relates to a process control 
system which automatically senses connection of process 
devices and automatically configures the devices when 
sensed. 

2. Description of the Related Art 
Present-day process control systems use instruments, con- 
trol devices and communication systems to monitor and 
manipulate control elements, such as valves and switches, to 
maintain at selected target values one or more process 
variables, including temperature, pressure, flow and the Eke. 
The process variables are selected and controlled to achieve 
a desired process objective, such as attaining the safe and 
efficient operation of machines and equipment utilized in the 
process. Process control systems have widespread applica- 
tion in the automation of industrial processes such as the 
processes used in chemical, petroleum, and manufacturing 
industries, for example. 

Control of the process is often implemented using 
microprocessor-based controllers, computers or worksta- 
tions which monitor the process by sending and receiving 
commands and data to hardware devices to control either a 
35 particular aspect of the process or the entire process as a 
whole. The specific process control functions that are imple- 
mented by software programs in these microprocessors, 
computers or workstations may be individually designed, 
modified or changed through programming while requiring 
40 no modifications to the hardware. For example, an engineer 
might cause a program to be written to have the controller 
read a fluid level from a level sensor in a tank, compare the 
tank level with a predetermined desired level, and then open 
or close a feed valve based on whether the read level was 
45 lower or higher than the predetermined, desired level. The 
parameters are easily changed by displaying a selected view 
of the process and then by modifying the program usiog the 
selected view. The engineer typically would change param- 
eters by displaying and modify ing an engineer's view of the 
so process. 

Many process control systems include local field devices 
such as valves, motors, regulators and the like which are 
responsive to specific control protocols, such as Profibus, 
Fieldbus, CAN and the like, to implement various control 
55 function routines. Accordingly, these controllers are respon- 
sive to certain standard control protocols to implement 
control functionality in the field. The use of such standard 
conuol signal protocols can reduce the time and effort of 
developing a control system because a designer can use the 
60 same types of control signals from all devices responsive to 
the control protocol. 

In a conventional process control system, the local field 
devices are typically configured in the field, often by indi- 
vidually programming the local field devices using a hand- 
65 held field programmer. Individual programming of the field 
devices is time consuming and inefficient and often leads to 
incompatibilities between the device configuration and the 
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configuration of other devices aDd controllers in the process 
coDtrol system since a global view of the system is more 
difficult to sustain when individual devices are programmed 
independently. Usage of individual programming devices is 
inconvenient since multiple different programming devices 
typically must be used to program respective different field 
devices. 

Furthermore, local device failures, including temporary 
failures or local power disruptions, interrupt operations of 
the entire control system, sometimes causing extended 
downtime since each failing device must be reconfigured 
locally. 

What is needed is a process control system that allows 
individual field devices to be configured without local, 
independent programming. What is also needed is a process 
control system allowing configuration of the global system 
from a location remote from the local field devices so that a 
compatible global configuration is achieved while allowing 
peripheral elements which are configured in a suitable global 
manner, to operate independently to achieve control func- 
tionality. 

Configuration of the global system is based on parameters 
that describe the particular field devices that make up the 
system. However, the control protocols for communicating 
with the field devices may be insufficient to convey param- 
eters that are sufficient to configure the system. For example, 
the system management specification of the Ficldbus pro- 
tocol defines three states for a device including an INITIAL- 
IZED state, an UNINITIALIZED state, and a system man- 
agement operational (SM OPERATIONAL) state. The 
three defined states are sufficient to describe the behavior of 
a device from the perspective of the system management, 
but are not adequate for describing a device from the 
perspective of either the fieldbus interface or software 
engineering tools for analyzing, controlling, or displaying 
the status of a device. This insufficiency is highly notable 
when configuration involves the operation of commission- 
ing a device that is attached to the Fieldbus link in an 
UNINITIALIZED state. 

What is further needed is a process control system that 
differentiates between Fieldbus device slates to support 
automatic sensing of devices and online address assignment 
of devices. 

SUMMARY OF THE INVENTION 
In accordance with an aspect of the present invention, a 
control system controls one or more interconnected devices 
according to a defined control configuration. The control 
system automatically senses a device that is connected to the 
control system but not included in the control configuration 
definition. The control system supplies initial interconnect 
information to the connected device sufficient to upload 
configuration parameters from the device to the control 

In accordance with a further aspect of the present 
invention, a digital control system with a predetermined 
configuration automatically senses the connection to a net- 
work of a digital device tbat is not included in the prede- 
termined configuration. The digital device is assigned tem- 
porary address information and placed in a temporary state, 
called a standby stale, in which the digital device supplies 
information to the digital control system allowing a user to 
access the digital device including access of device infor- 
mation and configuration parameters. Using the device 
information and configuration parameters, a user selectively 
commissions the digital device by assigning a physical 
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device tag, and a device address, and installing a control 
strategy to the digital device, thereby placing the digital 
device in an operational state in communication with the 
digital control system In the standby state, a user lnterro- 
5 gates to determine the type of device that is attached, 
determines the role of the device in the context of the digital 
control system assigns a physical device tag that assigns the 
determined role to the device, and verifies connection of the 
device to the network. Also in the standby state, the user 
10 initiates other applications applied to the device, including 
calibration of the device and configuring the device within 
the overall control scheme of the digital control system. 

In accordance with another aspect of the present 
invention, a control system differentiates between Fieldbus 
i-< device states beyond the stales defined according to the 
Fieldbus standard specification. The control system sets a 
physical device tag equal to the device identification (ID) for 
the devices that do not have tags, while the device is 
autosensed. A device attached to the Fieldbus link with the 
20 physical device tag set equal to the device ID is controlled 
in the manner of an UNINITIALIZED device. 

In accordance with an aspect of the present invention, 
automatic sensing of field devices is extended beyond a 
conventional input/ output level to the configuration of 
25 Fieldbus devices by a digital control system. 

In accordance with an embodiment of the present 
invention, a digital control system with a predetermined 
configuration automatically senses the connection to a nel- 
- 0 work of a digital device that is not included in the prede- 
termined configuration. The digital device is placed in a 
temporary state, called a standby state, in which the digital 
device supplies information to the digital control system 
allowing a user tn access the digital device, including access 
3< of device information and configuration parameters, 'lhe 
digital control system formats and displays the device infor- 
mation upon request by a user. The digital control system 
program also includes an automatic configuration program 
that responds to sensing of a new controller by automatically 
40 configuring the input/output (I/O) subsystem. The user adds 
a new controller without setting any physical switches or 
nodes. A user optionally supplies configuration information 
for a device into a database, prior to connection of a device. 
Upon connection of the device, the device is automatically 
4 ^ sensed and configured using the database configuration 
information, without setting of physical switches on the 

In accordance with another embodiment nf the present 
invention, a process control system includes a process, a 
50 plurality of controllers connected to the process, a worksta- 
tion connected to the plurality of controllers and including a 
user interface, and a software system including a network 
operating system, a user interface, and implementing an 
automatic sensing routine. The automatic sensing routine 
5« includes an executable logic for automatically sensing a 
connection of a device to a network and placing the device 
in a state accessible for communication by a user via a user 
interface. In the accessible stale, a user commissions the 
device and selectively initiates device-related applications. 
60 Many advantages are achieved by the described system 
and method. One advantage is that configuration of a control 
system is greatly facilitated. The physical connection of a 
device to the network automatically initiates inclusion of the 
connected device into the control system. The described 
65 system and method advantageously facilitates conformity 
between the configuration of a network and the physical 
interconnections of the network that serves as the basis for 
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the configuration. The described system and method assist a display of a system configuration. The screen 100 depicts 

programming of field devices from a remote location so that navigation selections which are operated by a user to select, 

individual field setting of the devices, using a local setting construct and operate a process control configuration The 

device, is not necessary. The system and method support navigation program supplies an initial state for navigating 
central programmability is highly useful to reduce system 5 across various tools and processors in a network. A user 

management costs and for reducing downtime of a process controls the navigation program to access libraries, areas, 

control system A further advantage is that configuration of process control equipment and security operations, 

the entire system, rather setting of individual devices, leads -yhe illustrative system configuration is described and 

to a system in which individual system settings are highly controlled with respect to a control system setup 102, control 
compatible. 10 strategies 104, and a physical setup 106. The functions of 

BRIEF DESCRIPTION OF THE DRAWINGS automatically sensing and automatically configuring a cod- 

„ , , , . ...... , trol system relate to tic physical setup 106. In particular, the 

The features of the invention beheved to be novel are ^ autonMticaU y sensing and automatically con- 

specmcaUy set forth m the appended claims. However the to*Jm a control system relate to the 
invention itself, both as to its structure and method of l5 JgJtoLiva activation of devices Id the control network 

operation, may best be understood by refemng to the ffld ^ decommissiocing of controllers 110. 

lollowing description and accompanying drawings. ' , .. , . 

„^ ?■ . ., . c c t j- 1 r In an iluslraUve embodiment, a process control system 

FIG 1 is a pictorial v«w of a front-of-screen display for ^ ^ ^ ^ 

a graphical user interface (GUI) displaying a system con- ^ fc accordance ^ i protoco] ]n ^ 

nguration. ... „ » Fieldbus protocol, a standard user application is defined 

FIG. 2 is a state transition diagram illustrating various bas£d 0Q bk)cks A bk)ck k a represenlation of various 

states of a field device. different types of application functions. Types 0 r blocks 

FIG. 3 is a flow chart illustrating a first operation of resource blocks> function blocks, and transducer 

commissioning a new device. blocks. 

FIG. 4 is a flow chart illustrating a second operation of 2S A K&Qmce b]ock describes characteristics of a fieldbus 

commissioning an unbound. device such as a device name, manufacturer, and serial 

FIG. 5 is a flow chart illustrating a third operation of num ber. A device includes only a single resource block, 

decommissioning a device. A Mock deflnes the comro ] system behavior. 

HG. 6 is a flow chart illustrating a fourth operation of Inpul ^ outpu[ parameters 0 f function blocks may be 

attaching a commissioned device without enablement of - ,u over , he fo^bus. The execution of each function 

operational powerup. block ^ precisely scheduled. A user application may include 

FIG. 7 is a flow chart illustrating a fifth operation of numerous function blocks. Examples of standard'function 

replacing a device. blocks include analog input (Ap, analog output (AO), bias 

; 0 FIG. 8 is a flow chart illustrating a sixth operation of ^ (B), Control Selector (CS), Discrete Input (Dl), Discrete 

O attaching an UNRECOGNIZED device. J " Output (DO), Manual Loader (ML), Proportional/Derivative 

{7 FIG. 9 is a flow chart illustrating a seventh operation of (PD), Proportional/Integral/Derivative (PID) and ratio (RA). 

decommissioning an unrecognized device. Function blocks are built into fieldbus devices to define a 

FIG. 10 is a flow chart illustrating an eighth operation of selected device functionality. In one example, a simple 

placing a decommissioned device in a standby condition. 4Q temperature transmitter may contain an Al function block. A 

FIGS. 11A, 11B and 11C illustrate a screen display, a first control valve often includes a PID function block and an AO 

schematic block diagram and a second schematic block block. 

diagram respectively, process control systems in accordance A transducer block decouples function blocks from local 

with a generalized embodiment of the present invention input and output functions for reading sensors and com- 

which furnishes a capability to create a new control template „ 5 manding output hardware. Transducer blocks contain infor- 

and a capability to modify' an existing control template for mation such as calibration data and sensor type. Typically a 

only one view, such as an engineering view. user application uses one transducer block for each input or 

FIG. 12 is a schematic block diagram showing the process output fuuctiou block, 

control environment in a configuration implementation and Another object defined in the user application includes 

a run-lime implementation. so link objects for defining the links between function block 

FIG. 13 is a block diagram illustrating a user interface for inputs and outputs internal to the device and across the 

usage with both configuration and run-lime models of the fieldbus network. Trend objects allow local trending of 

process control environment. function block parameters for access by other devices. Alert 

FIG. 14 is a thematic block diagram which depicts a objects are used to allow reporting of alarms and events on 

hierarchical relationship among system objects of a configu- 55 the fieldbus. View objects are predefined groupings of block 

ration model in accordance with an embodiment of the parameter sets that are used in the human/machine interface, 

present invention. The function block specification defines four views for each 

FIG. 15 illustrates a method for automatically sensing and <yP e of block - 

incorporating a controller/ multiplexer into a run-time sys- Referring to FIG. 2, a state transition diagram illustrates 

tem _ * 60 the various states of a field device. The field device slates 

FIG. 16 is a flow chart illustrates steps of an automatic mclude aE offlme state 202 ' « unrecognized state 204, a 

configuration routine for configuring a physical I/O device. standby state 206, a commissioned slate 208, and an 

unbound state 210. The state of a field device is determined 

DETAILED DESCRIPTION OF TIE PREFERRED by several parametcrs including a system management state 

EMBODIMENTS 65 (SM-State), a physical device tag (PD-Tag), a device 

Referring to FIG. 1, a front-of-screen display, also called address, device revision information (Rev*), and a device 

a "screen" 100, for a graphical user interface (GUI) depicts identification (Device-ID). In the illustrative embodiment, a 
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device in the commissioned slate 208 is a Fieldbus device 
that is available for control strategy configuration and instal- 
lation. A decommissioned device is a device that has been 
removed from the commissioned state 208. 

Several events occur that generate a state transition of a 
plurality of stale transitions Tl through T14. One or more 
actions arc performed during each state transition. 

Astate transition '11 is caused by the event in which a field 
device residing at a temporary address is queried with a 
system management identify service (SM-IDENTIFY) and 
the query determines that the device has a cleared physical 
device tag. The state transition Tl changes from a NUM. 
slate to an OFFLINE stale by allocating a standby address 
for the field device. Executing logic, typically in the form of 
firmware, software, or hardware, executes a set physical 
device tag service (SET-PD-TAG) to set the physical device 
tag identical to the device identification of the field device. 
Executing logic also uses a set device address service 
(SET-ADDRESS) to send a standby address to the field 
device. 

Astate transition T2 is caused by the event in which a field 
device residing at a temporary address is queried with a 
system management identify service (SM-IDENTIFY) and 
the query determines that the device has a physical device 
tag that is identical to the device identification of the device. 
The stale transition T2 changes from a NULL state to an 
OFFLINE state by allocating a standby address for the field 
device. Executing logic uses a set device address service 
(SET-ADDRESS) to send a standby address to the field 

Astate transition T3 is caused by the eveni in which a field 
device residing at a temporary address is queried with a 
system management identify service (SM -IDENTIFY) and 
the query determines that the device has a physical device 
tag and a device identification configured for the current 
process control system network link. The state transition T3 
changes from a NULL state to an OFFLINE state using 
executing logic that employs the set device address service 
(SET-ADDRESS) to send an assigned address to the field 
device. 

Astate transition T4 is caused by the event in which a field 
device residing at a temporary address is queried with a 
system management identify service (SM-IDENTIFY) and 
the query determines that the device has a physical device 
tag and a device identification not configured for the current 
process control system network link. The state transition T4 
changes from a NULL state to an UNRECOGNIZED state. 

A state transition T5 is caused by an event in which the 
device appears at a temporary address and the device is 
being commissioned by a user. The state transition T5 
changes from an OFFLINE state to an OFFLINE state using 
executing logic, typically in the form of firmware, software, 
or hardware, that executes a set physical device tag service 
(SET-PD-TAG) to clear the physical device tag of the field 
device. Executing logic also executes a set physical device 
tag service (SET-PD-TAG) to send an assigned physical 
device tag to the field device. Executing logic further uses a 
set device address service (SET-ADDRESS) to send an 
assigned address to the field device. 

A state transition T6 is caused by an event in which the 
device appears at a temporary address and the device is 
being decommissioned by a user. The state transition T6 
changes from an OFFLINE state to an OFFLINE state using 
executing logic that executes a set physical device tag 
service (SET-PD-TAG) to clear the physical device tag of 
the field device. 
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A state transition T7 is caused by an event in which a user 
requests to place a decommissioned device in standby. The 
state transition 17 changes from an OFFLINE state to an 
OFFLINE state by allocating a standby address for the field 
5 device. Executing logic executes a set physical device tag 
service (SET-PD-TAG) to set the physical device lag iden- 
tical to the device identification of the field device. Execut- 
ing logic also uses a set device address service (SET- 
ADDRESS) to send a standby address to the field device. 
10 A state transition T8 is caused by an event in which the 
field device appears at the standby address. The stale tran- 
sition T8 changes from an OFFLINE state to a STANDBY 
state through executing logic that reads device revision 
information from the resource block. 
35 A state transition T9 is caused by an event in which the 
field device appears at the assigned address. The state 
transition T9 changes from an OFFLINE stale to a COM- 
MISSIONED. 

A state transition HO is caused by a user requesting to 
20 commission a device in the STANDBY state. The state 
transition T10 changes from the STANDBY slate to ihe 
OFFLINE state through executing logic that uses a clear 
address service (CLEAR -ADDRESS) to clear the device 
^ address. 

^ A state transition Til is caused by a user requesting to 
decommission a device in the STANDBY state. The slate 
transition Til changes from the STANDBY state to the 
OFFIJNE state through executing logic that uses a clear 
3tJ address service (CLEAR-ADDRESS) to clear the device 

A state transition H2 is caused by a user requesting to 
decommission a device in the COMMISSIONED state. The 
state transition T12 changes from the COMMISSIONED 
35 state to the OFFLINE state through executing logic that uses 
a clear address service (CI .EAR-ADDRESS) to clear the 
device address. 

A state transition H3 is caused by a user requesting to 
decommission a device in the INITIALIZED state ot the 
40 Fieldbus system management states. The state trausitiou T13 
changes from the UNRECOGNIZED state to the OFFLINE 
state through executing logic mat executes a set physical 
device tag service (SET-PD-TAG) to clear the physical 
device tag of the field device. 
45 A state transition T14 is caused by a user requesting to 
decommission a device in the SM-OPERATIONAL state of 
the Fieldbus system management states. The state transition 
T14 changes from the UNRECOGNIZED state to the 
OFFLINE state through executing logic that uses a clear 
so address service (Cf. EAR-ADDRESS) to clear the device 
address. 

In accordance with Ihe Fieldbus standard, to operate 
properly a Fieldbus device has a unique device address 
(network address) and a unique physical device lag. Each 
55 device connected to the process control system network link 
has a unique node designator. A data link specification 
specifies a range of allowable values for node designators 
including a range for permanent devices, a range for tem- 
porary addresses, and a range for visitor devices. The 
60 temporary addresses are used by devices that are not pres- 
ently in the SM-OPERATIONAL state. The Fieldbus inter- 
face maintains partitioning of the address space for perma- 
nent devices into three sets. One set, called "assigned 
addresses", includes addresses assigned to devices with a 
65 specific physical device tag, regardless of whether the device 
is present on the bus. The assigned addresses is assigned 
using a software engineering tool on the basis of information 
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input by a user relating to Link-Active-Scheduler takeover 
preference. A second set, termed "standby addresses'", 
describes devices in the SM-OPERATIONAL state but have 
no device addresses assigned. The standby addresses are 
managed by the Fieldbus interface. The third set of 5 
addresses are addresses outside the first and second sets and 
refer to unused addresses. 

The small number of temporary addresses complicates 
autosensing and online address assignment. Standby 
addresses are defioed and utilized to support functionality of 10 
the autosensing and online address assignment operations. 
The assigned address set and the standby address set are 
defined to be equal to the number of potential devices 
connected to the process control system network link. For 
example, if sixteen devices may be potentially connected to 15 
the process control system network, then sixteen assigned 
addresses are defined and sixteen standby addresses are 
defined. 

The device revision information includes a manufactur- 
er's identification (MANUKAC-1D), a device type (DEV- 20 
TYPE), a device revision (DEV-REV), and a device descrip- 
tion revision (DD-REV). 

In the offline state 202 a field device is recently attached 
to a process control system network or is in the process of ^ 
being commissioned or decommissioned. The offline state 
202 includes device states having a plurab'ty of parameter 
combinations. In a first offline state 202, the system man- 
agement state is UNINITIALIZED and the physical device 
tag is cleared. In a second offline state 202, the system 3Q 
management state is INITIALIZED and the physical device 
tag is read from the physical device and displayable on a 
screen. In cither of the offline states 202, the device address 
is a temporary address, the revision information is not 
available, and the device identification is read from the 3< 
device and displayable on the screen. 

In the unrecognized state 204, the field device physical 
device tag and the device identifies don do not match the 
values thai are commissioned for a device that is connected 
to the process control system network. The unrecognized 40 
state 204 includes device states having a plurality of param- 
eter combinations. In a first unrecognized state 204, the 
system management slate is INITIALIZED with a device 
address that is a temporary address. In a second unrecog- 
nized state 204, the system management state is 45 
SM-OPERATIONAL with a device address that is a standby 
address or an assigned address. In either unrecognized state 
204, the physical device tag is read from the device and 
displayable on the screen, the device revision is not 
available, and the device identification is read from the 50 
device and displayable on the screen. 

In the standby state 206, the field device is not yet 
autosensed and is therefore not available for configuration in 
the control strategy or included in Link-Active-Scheduler 
(LAS) schedules of the system management configuration. 55 
In the standby state 206, function block execution and link 
communications aTe disabled. Note that a I. ink-Active- 
Scheduler is a deterministic centralized bus scheduler that 
includes a list of transmit times for all data buffers in all 
devices that are to be cyclically transmitted. When a device 6a 
is due to send a data buffer, the Link-Active-Scheduler 
issues a compel data (CD) message to the device. Upon 
receipt of the CD message, the device broadcasts or "pub- 
lishes" the data in the buffer to all devices on a field device 
bus and the broadcasting device is defined to be a "pub- 65 
lisber". Any device that is configured to receive the data is 
defined to be a "subscriber". Scheduled data transfers are 
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typically used for the regular, cyclic transfer of control loop 
data between devices on the fieldbus. 

In the standby state 206, the system management stale is 
SM-OPERATIONAL, the physical device tag is equal to the 
device identification, and the device address is a standby 
address. The device revision information is read from the 
field device and displayable. The device identification is 
read from the device and displayable on the screen. 

The unbound state 210 is a configuration placeholder for 
a field device that is to be physically attached subsequently. 
The unbound state 210 supports configuration of control 
strategies utilizing the function blocks in a field device that 
is not yet connected. In the unbound state 210, the system 
management stale is not yet applicable but the physical 
device tag is specified by a user and the device address is 
assigned by the user. The device revision information set 
according to the most recent commission or configuration. 
The device identification is cleared. 

In the commissioned state 208, the field device is avail- 
able for control strategy configuration and installation. The 
system management slate is SM-OPERATIONAL, the 
physical device tag is specified by a user, and the device 
address is assigned by the user. The device revision infor- 
mation is read from the field device and displayable on the 
screen. The device identification is read from the field 
device, stored in a field configuration database, and display- 
able on a display screen. 

Several operations or "use cases" are defined for control- 
ling commissioning and decommissioning of field devices. 

Referring to FIG. 3, a flow chart illustrates a first opera- 
tion or "use case" which describes an operation of commis- 
sioning a new device 300. Prior to the commissioning of the 
new device, the Fieldbus interface is operational. A device is 
connected to the process control system network. The device 
either has no physical device tag or has a physical device lag 
that is equal to the device identification. 

The operation of commissioning a new device 300 results 
in a condition in which the device is assigned a new physical 
device lag and a device address, and the device is ready for 
function block configuration. The new field device is entered 
into the process control system network database with the 
device identification bound and the device revision infor- 
mation set. An engineering software tool that displays the 
process control system network status displays the new 
device as a COMMISSIONED device. 

In a first step 302, the field device appears in the "live list" 
at a temporary address. A"live list" is a list of all devices that 
are properly responding lo a pass token (PT) message. All 
devices on a fieldbus are allowed to send unscheduled 
messages between the transmission of scheduled messages. 
The Link-Active-Scheduler grants permission to a device to 
use the fieldbus by issuing a pass token (FT) message lo the 
device. When the device receives the PT, it is allowed to 
send messages until the messages are complete or until a 
maximum allotted token hold time has expired. As a highest 
priority activity, the Link-Active-Scheduler accesses a CD 
schedule containing a list of actions that are set to occur on 
a cyclic basis. At a scheduled time, the Link-Active- 
Scheduler sends a compel data (CD) message to a specific 
data buffer in the fieldbus device. The device immediately 
broadcasts a message to all devices on the fieldbus. The 
Link-Active-Scheduler performs remaining operations 
between scheduled transfers. The Link-Active-Scheduler 
continually adds new devices to the field bus by periodically 
sending probe node (PN) messages to addresses that are not 
on the live list. If a device is present at the address and 
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receives the PN, the device immediately returns a probe 
response (PR) message. If a device responds with the PR 
message, the Link-Active-Schcduler adds the device to the 
live list and confirms by sending the device a node activation 
(NA) message. A device remains on the live list so long as 5 
the device responds properly to PTs. When a device is added 
or removed from the live list, the Link-Active-Scheduler 
broadcasts changes to the live list to all devices to allow each 
device to maintain a current copy of the live list. 

Id a second step 304, the interface queries the field device 10 
using a system management identify service (SM- 
IDENTIFY) and determines whether the field device is in 
the UNINITIALIZED state with no physical device tag set 
or in the INITIALIZED state having a physical device tag 
thai is equal to the device idenlificatioD. The interface then 15 
allocates 306 a standby address for the field device. 

A logical step 308 directs that a previously UNINITIAL- 
IZED device, in step 310, sets the physical device tag of the 
field device identical to the device identification using a set 
physical device tag service (SET-PD-TAG), thereby placing '° 
the field device in the INITIALIZED state. The standby 
address is sent to the field device 312 using a set address 
service (SET- ADDRESS), advancing the field device from 
the INITIALIZED stale to the SM-OPERATIONAL state. ^ 
At this point the field device appears in the "live list" at a 15 
standby address 314. Device revision information is read 
from the resource block 316. In step 318, an executing 
software engineering tool displays the field device as a 
STANDBY device. ' , Q 

Id step 320, a new user assigns a new physical device tag 
to the field device. The physical device tag is constrained to 
be unique and not the same as the device identification. 
During the assignment of the physical device tag, a device 
address is assigned to the field device using a software „ 
engineering tool and the Link-Active-Schcduler takeover 
preference is set to "selectable". The device revision infor- 
mation is read from the field device and written to the 
process control system network database. The interface 
changes the state of the field device 322 to the INITIAL- 40 
IZED state using a clear address service (CLEAR- 
ADDRESS). The field device appears in the "live list" at a 
temporary address 324. 

In a step 326, the interface queries the field device using 
a system management identify service (SM-IDENTIFY) and 45 
recognizes the field device by the device identification. The 
interface uses the set physical device tag service (SET-PD- 
TAG) to clear the physical device tag 328, thereby changing 
the field device state to the UNINITIALIZED state, lie set 
physical device tag service (SET-PD-TAG) is then used to 50 
send the assigned physical device tag to the field device 330, 
changing the field device state to the INITIALIZED state. 
The set address service (SET-ADDRESS) is called to send 
the assigned address to the field device 332, placing the field 
device iD the system management operational state (SM- 55 
OPERATIONAL). The field device appears in the "live list" 
at the assigned address 334. In the process control system 
network database, the device identification is bound 336 to 
the device. The software engineering tool displays the field 
device as a COMMISSIONED device. 60 

Referring to FIG. 4, a flow chart illustrates a second 
operation nr "use case" which describes an operation of 
commissioning an unbound device 400. Prior to the com- 
missioning of the unbound device, the Fieldbus interface is 
operational. A field device has been created in the process 65 
control system network database and a physical device tag 
and a device address are assigned to the field device. 
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However, the field device is not bound to a device identi- 
fication. The process control system network database has 
also been initialized to contain device revision information 
read from the field device. A software engineering tool 
displays the field device as an UNBOUND device. The 
UNBOUND device to be commissioned is either a Held 
device with no physical device tag or a field device having 
a physical device tag that is identical to the device identi- 
fication. The UNBOUND field device is commissioned to 
place the field device on the process control svstem network 
link. 

The operation of commissioning an UNBOUND device 
400 results in a condition in which the device is configured 
with a physical device tag and an assigned device address, 
and the device is ready for function block configuration. The 
new field device is entered into the process control system 
network database with the device identification bound. An 
engineering software tool that displays the process control 
system network status displays the device as a COMMIS- 
SIONED device. 

In a first step 402, the field device appears in the "live list" 
at a temporary address. In a second step 404, the interface 
queries the field device using a system management identify 
service (SM-IDENTIFY) and determines whether the field 
device is in the UNINITIALIZED state with no physical 
device tag set or in the INITIALIZED state having a 
physical device tag that is equal to the device identification. 
The interface then allocates 406 a standby address for the 
field device. 

A logical step 408 directs that a previously UNINITIAL- 
IZED device, in step 410, sets the physical device tag of the 
field device identical to the device identification using a set 
physical device tag service (SET-PD-TAG), thereby placing 
the field device in the INITIALIZED state, The standby 
address is sent to the field device 412 using a set address 
service (SET-ADDRESS), advancing the field device from 
the INITIALIZED state to the SM-OPERATIONAL state. 
At this point the field device appears in the "live list" at a 
standby address 414. Device revision information is read 
from the resource block 416. In step 418, an executing 
software engineering tool displays the field device as a 
STANDBY device. 

In step 420, a user assigns a physical device tag to the field 
device by associating the field device with the pre- 
configured device. The device revision information is read 
from the field device to ascertain that the information 
matches the device revision information in the process 
control system network database for the preconfigured 
device. If the device revision information of the device does 
not match the database, the user may override the database, 
reading the device revision information from the field device 
and writing the information to the process control system 
network database. Alternatively, the device revision infor- 
mation for an UNBOUND device may be made blank, 
allowing any physical device to be bound with the 
UNBOUND device. The interface changes the state of the 
field device 422 to the INITIALIZED stale using a clear 
address service (CLEAR-ADDRESS). The field device 
appears in the "live list" at a temporary address 424. 

In a step 426, the interface queries the field device using 
a system management identify service (SM-IDENTTFY) and 
recognizes the field device by the device identification. The 
interface uses the set physical device tag service (SET-PD- 
TAG) to clear the physical device tag 428, thereby changing 
the field device state to the UNINITIALIZED state. The set 
physical device tag service (SET-PD-TAG) is then used to 
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send the assigned physical device tag to the field device 430, 
changing the" field device state to the INITIALIZED state. 
The set address service (SET-ADDRESS) is called lo send 
the assigned address to the field device 432, placing the field 
device in the system management operational state (SM- 
OPER ATI ONAL). The field device appears in the "live list" 
at the assigned address 434. In the process control system 
network database, the device identification is bound 436 to 
the device. The software engineering tool displays the field 
device as a COMMISSIONED device. 

Referring to FIG. 5, a flow chart illustrates a third 
operation or '"use case" which describes an operation of 
decommissioning a device 500. Afield device is decommis- 
sioned for several reasons. For example, when a Fieldbus 
device is obsolete, a user may wish lo clear a network 
interconnection structure of nonfunctioning branches so that 
the process control system no longer expends resources on 
the obsolete device. Also, a user may suspect that a Fieldbus 
device is malfunctioning and degrading operations of a 
segment uf a network interconnection structure. The user 
may diagnose the problem by having the process control 
system ignore the suspected Fieldbus device temporarily to 
determine whether the remaining devices in the segment 
operate properly. 

Prior to the operation of decommissioning a device, the 
Fieldbus interface and the field device are operational and 
the field device appears in the live list at the assigned or 
standby address. A software engineering tool displays the 
field device as a COMMISSIONED or STANDBY device. 
The software engineering tool executes a routine that pre- 
pares the field device for decommissioning, for example by 
clearing function block tags and clearing an 
OPERATIONAL-POWERUP flag. 

The operation of decommissioning a device results in a 
condition in which the physical device tag of the field device 
is cleared and the field device is prepared to be removed 
from the process control system network link. The process 
control system network database entry for the field device 
designates the device identification as in an unbound con- 
dition. The software engineering tool displays the device 
identification as an UNBOUND device and displays the 
physical device as an OFFLINE device. 

The operation of decommissioning a device 500 begins 
when a user selects a "Decommission" operation for the 
field device 502. A graphic user interface includes a software 
engineering tool that issues a "Decommission" command to 
an appropriate controller within the process control system. 
The decommission command specifies a target I/O 
subsystem, card and port identifiers, and the device identi- 
fication of the field device lo be decommissioned. The 
device identification is specified since another device with 
the same physical device tag may be present in an UNREC- 
OGNIZED state. The interface changes the state of the field 
device 504 to the INITIALIZED state using a clear address 
service (CLEAR -ADDRESS). The field device appears in 
the "live list" at a temporary address 506. 

In a step 508, the interface queries the field device using 
a system management identify service (SM-IDENTIFY) and 
recognizes the field device by the physical device tag and the 
device identification. The interface uses the set physical 
device tag service (SET-PD-TAG) to clear the physical 
device tag 510, thereby changing the field device state to the 
UNINITIALIZED state. 

In the process control system network database, the 
device identification is unbound and the software engineer- 
ing tool displays the field device as an UNBOUND device 
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512. In a next step 514, the software engineering tool 
displays the field device as an OFFLINE device. 

A network interface card stores a designation that the field 
device has been decommissioned 51 6 and does not move the 

5 field device to a STANDBY address unless directed by the 
user. If the decommissioned device is not move to a 
STANDBY address, the interface card tracks the field device 
until the field device advances off the live list. 

Referring to FIG. 6, a flow chart illustrates a fourth 

30 operation or "use case" which describes an operation of 
attaching a commissioned device without enablement of 
operational powerup 600. Prior to the operation of attaching 
a commissioned device 600, the Fieldbus interface is opera- 
tional. The configuration of the Fieldbus interface includes 

5 5 the field device in an attached condition. The physical device 
tag and the device identification of the field device are 
matched. Following the operation of attaching a commis- 
sioned device 600, the field device has an assigned address. 
The field device appears in the "live list" at a temporary 

„ 0 address 602. In a step 604, the interface queries the field 
device using a system inauagemeut identify service (SM- 
IDENTIFY) and recognizes the field device by the physical 
device lag and the device identification as pari of the 
Fieldbus interface configuration. The set address service 

2S (SET-ADDRESS) is called to send the assigned address to 
the field device 606, placing the field device in the system 
management operational state (SM-OPERATIONAL). The 
field device appears in the "live list" at the assigned address 
608. 

30 Referring to FIG. 7, a flow chart illustrates a fifth opera- 
tion or "use case" which describes an operation of replacing 
a device 700. A device is replaced by decommissioning the 
current field device 702 connected to the process control 
system network link, if possible, and commissioning a 

3S replacement to the UNBOUND device 704. The step of 
decommissioning the current field device 702 is described in 
detail with reference to FIG. 5. The step of commissioning 
a replacement to the UNBOUND device 704 is described 
with reference to FIG. 4. 

40 Referring to FIG. 8, a flow chart illustrates a sixth 
operation or "use case" which describes an operation of 
attaching an UNRECOGNIZED device 800. Prior to the 
operation of attaching a commissioned device 600, the 
Fieldbus interface is operational. A field device is attached 

45 which has a physical device tag and a device identification 
that is not configured for the current process control system 
network link. Following the operation of attaching an 
UNRECOGNIZED device 800, the field device is identified 
and the software engineering tool displays the device as n 

50 UNRECOGNIZED device. The operation of attaching an 
UNRECOGNIZED device 800 may be performed without 
use of the software engineering tool. 

The field device appears in the "live list" 802. In a step 
804, the interface queries the field device using a system 

55 management identify service (SM-IDENTIFY) and deter- 
mines that the physical device lag and the device identifi- 
cation do not match a field device in the present configura- 

Referring to FIG. 9, a flow chart illustrates a seventh 
60 operation or "use case" which describes an operation of 
decommissioning an unrecognized device 900. Prior to the 
operation of decommissioning an unrecogni7£d device, the 
Fieldbus interface is operational. The field device is identi- 
fied which has a physical device tag and a device identifi- 
«5 cation that are not configured for the present process control 
system network link. A software engineering tool displays 
the field device as an UNRECOGNIZED device. 
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The operation of decommissioning an unrecognized 
device 900 results in a condition in which the physical 
device tag of tbe field device is cleared and the field device 
is prepared to be removed from tbe process control system 
network link The software engineering tool displays the 
field device as an OFFLINE device. 

The operation of decommissioning an unrecognized 
device 900 begins when a user selects a •'Decommission" 
operation for the field device 902. A graphic user interface 
includes a software engineering tool that issues a "Decom- 
mission" command to an appropriate controller within the 
process control system. The decommission command speci- 
fies a target I/O subsystem, card and port identifiers, and the 
device identification of the field device to be decommis- 
sioned. 

If the field device is in the INITIALIZED state, logic step 
904 directs the decommissioning operation 900 to a clear the 
physical device tag step 912. Otherwise, the interface 
changes the state of the field device 906 to the INITIAL- 
IZED state using a clear address service (CLEAR- 
ADDRESS). The field device appears in the "'live list" at a 
temporary address, 908. 

In a step 910, the interface queries the field device using 
a system management identify service (SM-1DENT1FY) and 
recognizes the field device by the physical device tag and the 
device identification. The interface uses tbe set physical 
device tag service (SET-PD-TAG) to clear the physical 
device tag 912, thereby changing the field device state to the 
UNINITIALIZED state. In a next step 914, tbe software 
engineering tool displays the field device as an OFFLINE 
device. 

A network interface card stores a designation that the field 
device has been decommissioned 916 and does not move the 
field device to a STANDBY address unless directed by the 
user. If the decommissioned device is not move to a 
STANDBY address, the interface card tracks the field device 
until the field device advances off the live list. 

Referring to FIG. 10, a flow chart illustrates an eighth 
operation or ''use case" which describes an operation of 
placing a decommissioned device in a standby condition 
1000. Prior to the operation of placing a decommissioned 
device in a standby condition 1000, tbe Ficldbus interface is 
operational. A field device is decommissioned and in the 
OFFLINE state. 

The operation of placing a decommissioned device in 
standby 1000 results in a condition in which the field device 
is placed at a standby address with the physical device tag 
of the field device set identical to the device identification. 
The software engineering tool displays the field device as a 
STANDBY device. 

The operation of placing a decommissioned device in 
standby 1000 begins when a user selects a "Place in 
Standby" operation for the field device 1002. A graphic user 
interface includes a software engineering tool that issues a 
"Place in Standby" command to an appropriate controller 
within the process control system 1004. The decommission 
command specifies a target I/O subsystem, card and port 
identifiers, and the device identification of the field device to 
be placed in standby. 

The interface allocates a standby address 1006 for the 
field device. The set physical device tag service (SET-PD- 
TAG) is then used to set the physical device tag identical to 
the device identification 1008, changing the field device 
state to the INITIALIZED state. The set address service 
(SET- ADDRESS) is called to send the standby address to 
the field device 1010, placing the field device in the system 
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management operational state (SM-OPERATIONAL). The 
field device appears in the "live list" at the standby address 
1012. Device revision information is read from the resource 
block 1014. In step 1016, an executing software engineering 

5 tool displays the field device as a STANDBY device. 

A user may subsequently commission the field device 
1018, cither by creating a new device or binding the field 
device to an UNBOUND device in the process control 
system network database. Tbe techniques for commission- 

io ing a device are described with respect to FIGS. 3 and 4. 
Referring to FIG. 11A, a control system is shown. In 
general, the system 1 includes a main processing device, 
such as personal computer 2, that is connected to a local area 
network ("LAN") 3 via a local area network card. Although 

15 any local area network protocol may be used, a non- 
proprietary ethernet protocol is beneficial in many applica- 
tions because il allows, for communications with the local 
area network 3. The local area network 3 is dedicated to 
carrying control parameters, control data and other relevant 

20 information coDcerned in the process control system As 
such, the LAN 3 may be referred to as an area controlled 
network or ACN 3. The ACN 3 may be connected to other 
LANs for sharing information and data via a hub or gateway 
without affecting the dedicated nature of ACN 3. 

* s In accordance with standard ethernet protocol, a plurality 
of physical devices may be connected to tbe ACN 3 at 
various "nodes." Each physical device connected to the 
ACN 3 is connected at a node and each node is separately 
addressable according the LAN protocol used to implement 

30 ACN 3. 

To establish a redundant system, it may be desirable to 
construct ACN 3 from two or more ethemet systems such 
that the failure of a single ethernet or LAN system will not 

, 5 result in the failure of the entire system. When such "redun- 
dant etheniets" are used the failure of one ethernet LAN can 
be detected and an alternate ethernet LAN can be mapped in 
to provide for the desired functionality of ACN 3. 
The main personal computer ("PC") A forms a node on 

40 the ACN 3. The PC 2 may, for example, be a standard 
personal computer running a standard operating system such 
as Microsoft's Window NT system. Main PC 2 is configured 
to generate, in response to user input commands, various 
control routines that are provided via the ACN 3 to one or 

45 more local controllers identified as element 4 and 5 which 
implement the control strategy defined by the control rou- 
tines selected and established in main PC 2. Main PC 2 may 
also be configured to implement direct control routines on 
field devices such as pumps, valves, motors and the like via 

50 transmission across the ACN 3, rathei than through a local 
controller 4 or 5. 

Local controllers 4 and 5 receive control routines and 
other configuration data through the ACN 3 from PC 2. The 
local controllers then generate signals of various types to 

55 various field devices (such as pumps, motors, regulator 
valves, etc.) 6 through 15 which actually implement and 
perform physical steps in the field to implement the control 
system established by the routines provided by PC 2. 
Two types of field devices may be connected to local 

60 controller 4 and 5 including field devices 6 through 10 which 
are responsive to specific control protocol such as Field Bus, 
Profibus and the like. As those in the art will appreciate, 
there are standard control protocols (e.g. FieldBus) accord- 
ing to which specific protocol instructions are provided to a 

65 protocol-friendly field devices (e.g., a Fieldbus field 
devices) will cause a controller located within the field 
device to implement a specific function corresponding to the 
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protocol function. Accordingly, field devices 6 through 11 
receive protocol specific (e.g., FieldBus) control commands 
from cither the local controllers 4 and 5 or the personal 
computer 2 to implement a field device-specific function. 

Also connected to local controllers 4 aod 5 are non- 
protocol field devices 12 through 15, which are referred to 
as non-protocol because they do not include any local 
processing power and can respond to direct control signals. 
Accordingly, field devices 12 through 15 are not capable of 
implementing functions that would be defined by specific 
control protocol such as the FieldBus control protocol. 

Functionality is supplied to allow the non-protocol field 
devices 12 through 15 to operate as protocol-friendly (e.g., 
FieldBus specific) devices 6 through 11. Additionally, this 
same functionality allows for the implementation of the 
protocol-specific control routines to be distributed between 
the local field devices 6 through 11, the local controllers 4 
and 5 and the personal computer 2. 

The distribution of protocol-specific control roulines is 
illustrated in more detail in FIG. 11B. FIG. 11B refers to one 
portion of the system shown in FIG. 11A, specifically the 
personal computer 2, the ethernet 3, local controller 4, a 
smart field device 6 and a dumb device 12, in greater detail. 

Personal computer 2 includes program software routines 
for implementing standard functional routines of a standard 
control protocol such as the FieldBus protocol. Accordingly, 
personal computer 2 is programmed to receive FieldBus 
commands and to implement all of the functional routines 
for which a local field device having Fieldbus capabilities 
could implement. The ability and steps required to program 
personal computer 2 to implement FieldBus block function- 
ality will be clearly apparent to one of ordinary skill in the 

Connected to personal computer 2 by the ethernet 3 is 
local controller 4. Local controller 4 includes" a central 
processing unit connected to a random access memory 
which provides control signals to configure the central 
processing unit to implement appropriate operational func- 
tions. A read only memory is connected to the random access 
memory. The read only memory is programmed to include 
control routines which can configure the central processing 
unit to implement all of the functional routines of a standard 
control protocol such as FieldBus. Personal computer 2 
sends signals through ethernet 3 to the local controller 4 
which causes one, more or all of the programmer routines in 
the read only memory to be transferred to the random access 
memory to configure the CPU to implement one, more or all 
of the standard control protocol routines such as tbe Field- 
Bus routines. 

Ine smart field device 6 includes a central processing unit 
which implements certain control functions. If the devices 
is, for example, a FieldBus device then the central process- 
ing unit associated with the smart field device 6 is capable 
of implementing all of the FieldRus functionality require- 
ments. 

Because the local controller 4 has the ability to implement 
FieldBus specific controls, controller 4 operates so that 
non-protocol device 12 acts and is operated as a FieldBus 
device. For example, if a control routine is running either in 
personal computer 2 or on the CPU of local cootroller 4, tbat 
control routine can implement and provide FieldBus com- 
mands to FieldBus device 6 and noD-protocol device 12, 
operating as a Fieldbus device. Since field device 6 is a 
FieldBus device, device 6 receives these commands and 
thereby implements the control functionality dictated by 
those commands. Non-protocol device 12, however, works 
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in conjunction with the central processing unit of local 
controller 4 to implement the FieldBus requirements such 
that the local controller in combination with the field device 
implements and operates FieldBus commands. 
5 In addition to allowing non-FieldBus device 12 to act and 
operate as a FieldBus device, the described aspect allows for 
distribution of FieldBus control routines throughout the 
system 1 shown in FIG. 11A. For example, lo the extent that 
a control routine initially requests field device 6 to irople- 
30 ment more than one FieldBus control routine, the system 1 
allows for control to be divided between the local controller 
4 and the local controller 5 such that a portion of the 
FieldBus control routines are being implemented by local 
controller 5 aod other FieldBus routines are implemented by 
15 the use of the FieldBus routines stored on local controller 4. 
The division of FieldBus routine implementation may allow 
for more sophisticated and faster control and more efficient 
utilization of the overall processing power of the system. 
Still further, the fact tbat personal computer 2 has the ability 
ao to implement FieldBus control routines, tbe FieldBus rou- 
tines are further distributed between the local controller 4 
and the personal computer 2. In this manner, the system 
allows personal computer 2 lo implement one or all of the 
FieldBus routines for a particular control algorithm. 
25 Still further, the system allows for the implementation of 
FieldBus controls to a non-FieldBus device connected 
directly to the ethernet 3 through use of the FieldBus control 
routines stored on personal computer 2 in the same manner 
that FieldBus routines are implemented on non-FieldBus 
so device 12 through use on the FieldBus routines stored on 
local controller 4. 

A process control environment 1100 is shown in FIG. 11 C 
and illustrates a control environment for implementing a 
digital control system, process controller or the like. The 
35 process control environment 1100 includes an operator 
workstation 1102, a laboratory workstation 1104, and an 
engineering workstation 1106 electrically interconnected by 
a local area network ("LAN") 1108 for transferring and 
receiving data and control signals among the various worfc- 
40 stations and a plurality of controller/multiplexers 1110. The 
workstations 1102, 1104, 1106 are shown connected by the 
LAN 1108 to a plurality of the controller/multiplexers 1110 
that electrically interface between the workstations and a 
plurality of processes 1112. In multiple various 
45 embodiments, the LAN 1108 includes a single workstation 
connected directly to a controller/multiplexer 1110 or alter- 
natively includes a plurality of workstations, for example 
three workstations 1102, 1104, 1106, and many controller/ 
multiplexers 1110 depending upon tbe purposes and require- 
50 ments of the process control environment 1100. In some 
embodiments, a single process controller/multiplexer 1110 
controls several different processes 1112 or alternatively 
controls a portion of a single process. 
In the process control environment 1100, a process con- 
55 trol strategy is developed by creating a software control 
solution on the engineering workstation 1106, for example, 
and transferring the solution via the LAN 1108 to the 
operator workstation 1102, lab workstation 1104, and to 
controller/multiplexer 1110 for execution. The operator 
60 workstation 1102 and lab workstation 1104 supply interface 
displays to the control/monitor strategy implemented in the 
controller/multiplexer 1110 and communicates to one or 
more of the controller/multiplexers 1110 to view the pro- 
cesses 1112 and change control attribute values according to 
65 the requirements of the designed solution. The processes 
1112 are formed from one or more field devices, wbicb may 
be smart field devices or conventional (non -smart) field 
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devices. The process 1112 is illustratively depicted as two 
Fieldbus devices 1132, a HART (highway addressable 
remote transducer) device 1134 and a conventional field 
device 1136. 

Id addition, the operator workstation 1102 and lab work- 5 
statioD 1104 communicate visual and audio feedback to the 
operator regarding the status and conditions of the controlled 
processes 1112. The engineering workstation 1106 includes 
a central processing unit (CPU) 1116 and a display and 
input/output or uscr-intcrfacc device 1118 such as a 1(J 
keyboard, light pen and the like. The CPU 1116 typically 
includes a dedicated memory 1117. The dedicated memory 
1117 includes a digital control system program (not shown) 
that executes od the CPU 1116 to implement control opera- 
lions and functions of the process control environment 1 1 00. 
The operator workstation 1102. the lab workstation 1104 and u 
other workstations (not shown) within the process control 
environment 1100 include at least one central processing 
unit (not shown) which is electrically connected to a display 
(not shown) and a user-interface device (not shown) to allow 
interaction between a user and the CPU. In one embodiment, 20 
the process control envirunmem 1100 includes workstations 
implemented using a Motorola 68040 processor and a 
Motorola 68360 communications processor running in com- 
panion mode with the 68040 with primary and secondary 
ethernet pom driven by the 68360 processor (SCC1 and 2 S 
SCC3 respectively). 

The process control environment 1100 also includes a 
template generator 1124 and a control template library 1123 
which, in combination, form a control template system 1120. 
A control template is defined as the grouping of attribute 30 
functions that are used to control a process and the meth- 
odology used for a particular process control function, the 
control attributes, variables, inputs, and outputs for the 
particular function and the graphical views of the function as 
needed such as an engineer view and an operator view. 35 

The control template system 1120 includes the control 
template library 1123 that communicates with the template 
generator 1124. The control template library 1123 contains 
data representing sets of predefined or existing control 
template functions for use in process control programs. The 40 
control template functions are the templates that generally 
come with the system from the system designer to the user. 
The template generator 1124 is an interface that advanta- 
geously allows a user to create new control template func- 
tions or modify existing control template functions. The 45 
created and modified template functions are selectively 
stored in the control template library 1123. 

The template generator 1124 includes an attributes and 
methods language generator 1126 and a graphics generator 
1128. The attributes and methods language generator 1126 50 
supplies display screens that allow the user to define a 
plurality of attribute functions associated with the creation 
of a new control template function or modification of a 
particular existing control template function, such as inputs, 
outputs, and other attributes, as well as providing display ss 
screens for enabling the user to select methods or programs 
that perform ihe new or modified function for the particular 
control template. The graphics generator 1128 furnishes a 
user capability to design graphical views to be associated 
with particular control templates. A user utilizes the data 60 
stored by the attributes and methods language generator 
1126 and the graphics generator 1128 to completely define 
the attributes, methods, and graphical views for a control 
template. The data representing the created control template 
function is generally stored in the control template library 65 
1123 and is subsequently available for selection and usage 
by an engineer for the design of process control solutions. 
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The process control environment 1100 is implemented 
using an object-oriented framework. An object-oriented 
framework uses object-oriented concepts such as class 
hierarchies, object states and object behavior. These 
concepts, which are briefly discussed below, are well known 
in the art. Additionally, an object-oriented framework may 
be written using object-onented programming languages, 
such as the C++ programming language, which are well- 
known in the art, or may be written, as is the case with the 
preferred embodiment, using a non-object programming 
language such as C and implementing an object-oriented 
framework in that language. 

The building block of an object-oriented framework is an 
object. An object is defined by a state and a behavior. The 
state of an object is set forth by fields of the object. The 
behavior of an object is set forth by methods of the object. 
Each object is an instance of a class, which provides a 
template for the object. A class defines zero or more fields 
and zero or more methods. 

lields are data structures which contain information 
defining a portion of the state of an object. Objects which are 
instances of the same class have the same fields. However, 
the particular information contained within the fields of the 
ohjects can vary from object to object. Each field can contain 
information that is direct, such as an integer value, or 
indirect, such as a reference to another object. 

A method is a collection of computer instructions which 
can be executed in CPU 1116 by computer system software. 
The instructions of a method are executed, i.e., the method 
is performed, when software requests that the object for 
which the method is defined perform the method. A method 
can be performed by any object that is a member of the class 
that includes the method. The particular object performing 
the method is the responder or the responding object. When 
performing the method, the responder consumes one or 
more arguments, i.e., input data, and produces zero or one 
result, i.e., an object returned as output data. The methods 
for a particular object define the behavior of that object. 

Classes of an object-oriented framework arc organized in 
a class hierarchy. In a class hierarchy, a class inherits the 
fields and methods which are defined by the superclasses of 
that class. Additionally, the fields and methods defined by a 
class are inherited by any subclasses of the class, i.e., an 
instance of a subclass includes the fields defined by the 
superclass and can perform the methods defined by the 
superclass. Accordingly, when a method of an object is 
called, the method that is accessed may be defined in the 
class of which the object is a member or in any one of the 
superclasses of the class of which the object is a member. 
When a method of an object is called, process control 
environment 1100 seiecls the method to run by examining 
the class of the object and, if necessary, any superclasses of 
the object. 

A subclass may override or supersede a method definition 
which is inherited from a superclass to enhance or change 
the behavior of the subclass. However, a subclass may not 
supersede the signature of the method. The signature of a 
method includes the method's identifier, the number and 
type of arguments, whether a result is returned, and, if so, the 
type of the result. The subclass supersedes an inherited 
method definition by redefining the computer instructions 
which are carried out in performance of the method. 

Classes which are capable of having instances are con- 
crete classes. Classes which cannot have instances are 
abstract cLasses. Abstract classes may define fields and 
methods which are inherited by subclasses of the abstract 
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classes. The subclasses of an abstract class may be other master database 1260 to the local databases 1262 as directed 

abstract classes; however, ultimately, within the class by a user. Part of the master database 1260 is a persistent 

hierarchy, tbe subclasses are concrete classes. database 1270. The persistent database 1270 is an object 

All classes defined in the disclosed preferred which transcends time so that the database continues to exist 

embodiment, except for mix-in classes which are described 5 after the creator of the database no longer exists and tran- 

below, are subclasses of a class, Object. Thus, each class that scends space so that the database is removable to an address 

is described herein arid which is not a mix-in class inherits space that is different from the address space at which the 

the methods and fields of class Object. database was created. The entire configuration implenjenta- 

Thc process control environment 1100 exists in a con- u'on 1210 is stored in the persistent database 1270. 
figuration model or configuration implementation 1210 and 30 The master database 1260 and local databases 1262 arc 
a run-time model or run-lime implementation 1220 shown in accessible so that documentation of configurations, statistics 
FIG. 12. In the configuration implementation 1210, the aDd diagnostics are available for documentation purposes, 
component devices, objects, interconnections and interrela- The nm-time implementation 1220 interfaces to the per- 
tionships within the process control environment 1100 are sistent database 1270 and to local databases 1262 to access 
defined. In the run-time implementation 1220, operations of H data structures formed by the configuration implementation 
the various component devices, objects, interconnections 1210. In particular, the run-Lime implementation 1220 
and interrelationships are performed. The configuration fetches selected equipment modules, displays and the like 
implementation 1210 and the run-time implementation L220 &om the local databases 1262 and the persistent database 
are interconnected bv downloading. The download language 1270. The run-time implementation 1220 interfaces to other 
creates system objects according To definitions supplied by 20 subsystems to install definitions, thereby installing objects 
a user and creates instances from the supplied definitions. that are used to create instances, when the definitions do not 
Specifically, a completely configured Device Table relating y et ejdst > instantiating run-time instances, and transferring 
to each device is downloaded to all Workstations on startup information from various source to destination objects, 
and when tbe Device Table is changed. For controller/ Device Tables are elements of the configuration database 
multiplexers 1110, a downloaded Device Table only includes 2 « that are local to devices and, in combination, define part of 
data for devices for which tbe controller/multiplexer 1110 is the configuration implementation 1210. A Device Table 
to initiate communications based on remote module data contains information regarding a device in tbe process 
configured and used in the specific controller/multiplexer control environment 1100. Information items in a Device 
1110. The Device Table is downloaded to the controller/ Table include a device ID, a device name, a device type, a 
multiplexer 1110 when other configuration data is down- 30 PCN network number, an ACN segment number, a simplex/ 
loaded. In addition to downloading definitions, the down- redundant communication flag, a controller MAC address, a 
load language also uploads instances and instance values. comment field, a primary internet protocol (IP) address, a 
The configuration implementation 1210 is activated to primary subnet mask, a secondary IP address and a second- 
execute in the run-time implementation 1220 using an ary subnet mask. 

installation procedure. Also, network communications 35 Referring to FIG. 13, a block diagram illustrates a user 
parameters are downloaded to each device when configura- interface 1300 for usage with both the configuration and 
tion data arc downloaded and when a value is changed. run-time models of the process control environment 1100 
The process control environment 1100 includes multiple shown in FIG. 11C. Part of the user interface 1300 is the 
subsystems with several of the subsystems having both a Explorer™ 1310, an interfacing program defined under tbe 
configuration and a run-time implementation. For example, 40 Windows NT™ operating system which features a device- 
a process graphic subsystem 1230 supplies user-defined based configuration approach. Another part of the user 
views and operator interfacing to the architecture of the interface 1300 is a module definition editor 1320 for inter- 
process control environment 1100. Tbe process graphic facing to the process control environment 1100 using a 
subsystem 1230 has a process graphic editor 1232, a part of control-based configuration approach, 
the configuration implementation 1210, and a process 45 The Explorers 1310 is operated by a user 10 select, 
graphic viewer 1234, a portion of the run-time implemen- construct and operate a configuration. In addition, the 
tation 1220. The process graphic editor 1232 is contacted to Explorer™ 1310 supplies an initial state for navigating 
the process graphic viewer 1234 by an intersubsystem across various tools and processors in a network. A user 
interface 1236 in the download language. The process controls the Explorer™ 1310 to access libraries, areas, 
control environment 1100 also includes a control subsystem 50 process control equipment and security operations. FIG. 13 
1240 which configures and installs control modules and illustrates the relationship between various tools that may be 
equipment modules in a definition and module editor 1242 accessed by a task operating within the process control 
and which executes the control modules and the equipment environment 1100 and the relationship between components 
modules in a run-time controller 1244. The definition and of the process control environment 1100 such as libraries, 
module editor 1242 operates within the configuration imple- 55 areas, process control equipment and security. For example, 
mentation 1210 and the run-time controller 1244 operates when a user selects a "show tags" function from within an 
within the run-time implementation 1220 to supply continu- area, a "tag list builder" is displayed, showing a list of 
ous and sequencing control functions. The definition and control and I/O flags. From the tag list builder, the user can 
module editor 1242 is connected to the run-time controller use an "'add tag" function to add a module to a list, thereby 
1244 by an intersubsystem interface 1246 in the download 60 invoking a '"module editor". 

language. The multiple subsystems are interconnected by a Referring to FIG. 14, a schematic block diagram illus- 

subsystem interface 1250. trates a hierarchical relationship among system objects of a 

The configuration implementation 1210 and the run-time configuration model 1400. The configuration model 1400 

implementation 1220 interface to a master database 1260 to includes many configuration aspects including control, I/O, 

support access to common data structures. Various local 65 process graphics, process equipment, alarms, history and 

(non-master) databases 1262 interface to the master database events. The configuration model 1400 also includes a device 

1260, for example, to transfer configuration data from the description and network topology layout. 
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The configuration model hierarchy 1400 is defined for 
usage by a particular set of users for visualizing system 
object relationships and locations and for communicating or 
navigating maintenance information among various system 
objecls For example, one configuration model hierarchy 5 
1400, specifically a physical plant hierarchy, is defined for 
usage by maintenance engineers and technicians for visual- 
izing physical plant relationships and locations and for 
communicating or navigating maintenance information 
among various instruments and equipment in a physical 10 
plant. An embodiment of a configuration model hierarchy 
1400 that forms a physical plant hierarchy supports a subset 
of the SP88 physical equipment standard hierarchy and 
includes a configuration model site 1410, one or more 
physical plant areas 1420, equipment modules 1430 and lf 
control modules 1440. 

The configuration model hierarchy 1400 is defined for a 
single process site 1410 which is divided into one or more 
named physical plant areas 1420 that are defined within the 
configuration model hierarchy 1400. The physical plant 20 
areas 1420 optionally contain lagged modules, each of 
which is uniquely instantiated within the configuration 
model hierarchy 1400. A physical plant area 1420 optionally 
contains one or more equipment modules 1430. An equip- 
ment module 1430 optionally contains other equipment ~s 
modules 1430, control modules 1440 and function blocks. 
An equipment module 1430 includes and is controlled by a 
control template that is created according to one of a number 
of different graphical process control programming lan- 
guages including continuous function block, ladder logic, or 30 
sequential function charting ("SFC"). The configuration 
model hierarchy 1400 optionally contains one or more 
control modules 1440. A control module 1440 is contained 
in an object such as a physical plant area 1420, an equipment 
module 1430 or another control module 1440. A control 35 
module 1440 optionally contains objects such as other 
control modules 1440 or function blocks. The control mod- 
ule 1440 is thus a container class, having instances which are 
collections of other objects. The control module 444 is 
encapsulated so that all of the contents and the implemen- 4Q 
tation of the methods of the control module are hidden. 

A controller/multiplexer is automatically sensed and 
incorporated into a run-time system as shown in FIG. 15. In 
step 2210, a controller/ multiplexer, upon connection to the 
ACN and application of power, automatically sends a 45 
request for identification or verify IP address assignment. 
The request message includes the MAC address of the 
controller/multiplexer. The request is handled by a 
"Plug&Play Network Configuration Service", which is 
known in the operating system art, at a master configuration 50 
controller/ multiplexer in step 2212. In step 2214, the 
"Plug&Play Nelwork Configuration Service" receives the 
request from the network to assign/verify an IP address, 
searches a table of configured devices for a MAC address 
match. If a match is found, in step 2216 the "Plug&Play 55 
Network Configuration Service" responds with the Device 
Name, Device ID, IP Address Information, Subnet Mask 
Information, ACN Segment Number and other items 
included in the Device Table. If no match is found, in step 
2218 the "Plug&Play Network Configuration Service" auto- 60 
maticaliy generates a default name for the device based on 
the controller/multiplexer MAC address (for example, 
Controller-000001) The new device is added to the database 
in a Device Scratch area in step 2220. 

In step 2222, using the Explorer™ a user selects each 65 
unassigned controller/multiplexer in the Device Scratch 
area, drags the selection to the appropriate ACN segment 
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and, and either adds the selection to the system as a new 
device or drops the selection to a pre-existing device con- 
figuration. If the unassigned controller/multiplexer is added 
as a Dew device, the configuration processing proceeds m the 
manner of manual incorporation of the device. In step 2224, 
a user is prompted for the real device name using the 
previously assigned name 'Controller-000001 ' as a default. 
If automatic address assignment is set, the new device is 
assigned the next Device ID and associated IP addresses and 
Subnet masks are automaticaUy assigned in step 2226. If 
manual address assignment is set, the device is automati- 
cally assigned the next Device ID and the user is prompted 
to enter the IP Addresses and Subnet Masks in step 2228. 
The MAC address for the controller/multiplexer is set to the 
MAC address of the 'Controller-000001' as dragged into the 
ACN segment. The new controller/multiplexer Name, 
Device ID, IP Address, Subnet Masks and ACN number are 
added to the device table in the database. The next request 
by an unconfigured controller/multiplexer is answered by 
the "Plug&Play Network Configuration Service". 

If a new controller/ multiplexer is dragged and dropped 
over an existing device, that device must be a controller/ 
multiplexer type device and have an unassigned MAC 
address. Accordingly, the MAC address of the previously 
entered controller/multiplexer is set to the MAC address of 
the ' Controller-000001 ' device which was dropped. The new 
controller/ multiplexer Name, Device ID, IP Addresses, 
Subnet Masks and ACN number are available for sending to 
the requesting controller/multiplexer by the "Plug&Play 
Network Configuration Service". 

The digital control system program 115 includes an 
auto-configure routine for automatically configuring the 
input/output (I/O) subsystem in response either to an "auto- 
configure" command by a user or in response to detection of 
a new controller/multiplexer. 

Referring to FIG. 16, a flow chart illustrates steps of an 
automatic configuration routine for configuring a physical 
I/O device. An auto-configure command may be directed to 
a Controller/Multiplexer 1110, causing each I/O subsystem 
in the Controller/Multiplexer 1110 to auto-configure. An 
auto-configure command may be directed to an I/O 
subsystem, causing each I/O Card in the I/O subsystem to 
aulo-configure. An aulo-configure command may also be 
directed to an I/O Card. 

The auto-configure operation for an I/O Card first inter- 
rogates the I/O Card at a particular card position lo deter- 
mine a Card Type in step 2310 and, implicitly for some I/O 
Cards, the number of I/O Ports in the I/O Card. If no I/O 
Card is previously created in the engineering database for 
that card position, an I/O Card of the appropriate type is 
defined and the appropriate number of I/O Ports are created 
in step 2312. If an I/O Card dues exist in Ihe engineering 
database for that card position, but the Card Type in the 
engineering database does not match the Card Type sensed 
at the card position, the auto-configure operation generates 
a graphic notification of the mismatch in step 2314 and 
interrogates a user lo determine whether the engineering 
database is to be changed to include the sensed Card Type. 
The Card Type in the engineering database is changed to the 
sensed Card Type in step 2316 if requested by the user. 

Once the Card Type is known, the auto-configuration 
program interrogates each I/O Port in accordance with trie 
Card Type in step 2318 to determine the Port Type and, if 
information is available, the number of I/O Devices on the 
I/O Port. If no I/O Port is previously created in the engi- 
neering database for that port address, an I/O Port of the 



